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Author's Notes to Reviewers (Rev 0.5, 11/9/99) 

The goal of the Dynamic Channel Change command is to allow both the upstream and downstream frequencies 
to be changed. They are combined into one command so that both may be changed at the same time. 

DCC is a direct substitution for UCC. In this proposal, DCC is backwards compatible with the former UCC. If 
compatibility were not an issue, I would recommend changing the upstream channel ID from a parameter to a 
TLV in both the DCC-REQ and DCC-GNT. That would allow for either upstream and/or downstream channel 
IDs to be specified. 

After specifying this change, there were a few other "laundry list" items regarding channel changing that needed 
to be added or clarified. 

In general, the main changes I made are: 

• Changed UCC to DCC. Added a downstream frequency TLV. 

• If the DCC fails, the CM retums to its previous channel instead of re-initializing. This should 
improve system integrity and trouble-shooting. 

The "laundry list" of items I added or changed are: 

• Added a registration technique TLV to DCC-REQ. This complements the ranging technique TLV 
that I had added long ago. Text added to explain both cases. 

• Added a success TLV to DCC-RSP. If the change is a failure, then the CM come back to the 
previous channel and reports a failure. Several failure codes are provided to aid in system integrity. 

• Text added to explain how to deal with outstanding bandwidth requests. 

• Text added to explain interaction with DCC, UGS services, and QoS reservations. 

• CMTS and CM state diagrams updated accordingly. 

• Appendix B: The number of UCC-REQ Retries was missing. DCC-REQ Retries added and 
specified at 3 retries. 

• Appendix H. 1 : Redrew the diagram. Clarified and updated text. Changed MUST to SHOULD on all 
upstreams being the same frequency. This is to allow for spectrum management techniques. 

• Appendix H.2 is completely new and explains the system impacts with DCC. 

I have formatted the submission in DOCSIS format. Text marked with a strike through can be ignored and is to 
make cross referencing work. Changes that will need to occur elsewhere in the DOCSIS document include: 

• Change all "UCC" references to "DCC" 

• Change all "Upstream Channel Change" references to "Dynamic Channel Change" 



Update on Rev 0.6, 2/14/00 

Aifler having the proposal reviewed by the DOCSIS 1 . 1 committee, I have made the following refinements 
before submitting this as an ECR: 

• Renumbering: Section 8 to Section 6. Section 9.3.3 to 9.3.4 
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• Unique DCC Command: 

• DCC will become a separate command from UCC and only apply to DOCSIS 1 . 1 

• T5 in appendix B lists both commands. 

• Changed UCID from a listed parameter into a TLV parameter for DCC-REQ and DCC-RSP. 
Renumbered parameters. Added description of registration TLV to DCC-REQ. Updated 
diagrams. 

• Renamed "Registration TLV" to "Configuration TLV" to better describe its function. I am open 
to other name possibilities, (later renamed to Connection TLV 2/17/00) 

• Maintenance Option: When the CMTS instructs the CM to use initial or station maintenance, the 
choice belongs to the CM, not which one comes first, (footnote 6.3.10. 1 .3) 

• SID/SAID/SFID Substitution on DCC-REQ: This was the only feature really missing from this 
proposal. It was part of the original proposal, but I took it out for simplification, I have now put it 
back in as it gives the CMTS flexibility in how it manages its addressing tables between channels. 

• DCC-RSP 

• I have defined this as being sent on the old channel only. It is needed there as all CMTS 
commands are ACKed, and this is how UCC works. On the new channel, the concept is to have 
UGS operation begin immediately. This means the CM and CMTS cannot afford to wait for a 
DCC-RSP to propagate to the CMTS before sending data. Without it (current proposal), the 
CMTS will have to rely on other techniques for detecting the presence of the CM on the new 
channel. Opinions are welcome on this. 

• Repeating the Upstream Channel ID and the Downstream Frequencies don't seem useful to me. 
I have left these in here because it was done that way in UCC. I have deleted them. 

• DCC-Status: The sole value of this TLV is to support a graceftil recovery from sending a CM 
into never-never land. In theory, this should never happen. In practice, it may, and this option is 
intended to improve the reliability of connections. The caveat was added that this only applies to 
channels which did not get re-configured. However, I am concerned that this TLV along with 
Til and T12 may create more test cases and comer cases, and might not be worth the 
complexity. I am open to deleting this. 

• DSx-RSP Confirmation Code: If CM issues a DSx for more BW, and the CMTS needs to do a 
DCC to obtain that bandwidth, the CMTS will allow the DSx to be successfiil and include a return 
code that the new bandwidth will not be available until a DCC is received. The CMTS will then 
follow the DSx transaction with a DCC transaction. Comment added to section 9 and section C,4 

• DSx and DCC Glare: Glare treatment between DSx and DCC. There are two options if the CM 
issues DSx simultaneous with the CMTS issuing a DCC. 

• (a) CMTS wins. DSx rejected. DCC proceeds. Giving the preference to the CMTS is consistent 
with the DSx glare scenarios. Or, 

• (b) CM wins. This allows the CMTS to re-evaluate the bandwidth requirements and allows the 
DCC command to be modified or canceled. This was the recommendation of the DOCSIS 1 . 1 
group so as to avoid altering the DSx state machines (this assumption would be confirmed. 
Wouldn't the CMTS state machines still be altered?). The potential downside is that a first DSx 
is given a confirmation code off success-pending-DCC, and the DCC gets delayed by a second 
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and independent DSx command from the same CM. Another issue is if the second DSx is on a 
different SID but from the same CM: is this glare? How easy/hard is it for the CMTS to surmise 
this? 

• Although the group had preferred option (b), I have submitted option (a) as I was not 
comfortable with the potential issues, I am open to discussion on this and am willing to change 
to (b) if it can be shown to work. 

• Also, CMTS should not issue a DSx if a DCC is outstanding, nor should it issue a DCC if a DSx 
is outstanding. 

• Comments added to the end of section 9. 

• Circular References: If CMTS does a DCC with re-range, the config file could cause the CM to 
come back to the original channel. This would cause a infinite loop. A note was added that the 
provisioning system should use either static or dynamic load balancing, not both. There is 
intentionally no structure which would allow the CMTS to override a config file parameter during 
registration. Comment added to section 9. 

• Appendix H: 

• H.l : rewrite of "constraints imposed by this topology" supplied by Victor Hou. 

• MUSTs and SHOULDs in Appendix H set to lower case. Appendix H becomes informative 
instead of normative. 



Update on Rev 0, 7, 2/20/00 

Grammar was cleaned up, along with some duplicate statements. The changes significant to the spec are: 

• Renumbering 

• From Section 6.3.10 to 6.3.20 and 6.3.1 1 to 6.3.21 since 6.3.10 is used by UCC. 

• The DOCSIS editor may with to include section 9 in "9.4 Dynamic Operation" instead of "9.3 
Standard Operation". 

• 6.3.10 UCC-REQ 

• Added a note indicating that the footnote needs updating. 

• 6.3.20.1.3 UCD Technique 

• Added this TLV 

• 6.3.20.1.4 Ranging Technique TLV 

• Removed the phase ''If this TLV is absent, the CM MUST perform ranging with initial maintenance. 
For backwards compatibility, the CMTS MUST accept a CM which ignores this tuple and performs 
initial maintenance" since DCC is only a DOCSIS 1.1 command. 

• Added a statement regarding the delay before operation as a result of the different ranging choices. 

• 6.3.20.1,5 Connection Technique TLV 

• Changed "Configuration TLV" to "Connection TLV" throughout the document. 

• 6.3.21 DCC-RSP 

• Removed the DCC-Status TLV. DCC-RSP now has no parameters. I did this because the the criteria 
for declaring a change-over successful was not consistent under all test conditions, and it was 
difficult to arrive at a criteria that the CMTS and CM could use reliably. Also, the old QoS resources 
were kept around for 35 sec instead of only 2 sec as they are now. I think this also simplifies the 
overall proposal without sacrificing quality. 

• 9.3.4 Changing Channels... 
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• Re-organized into 4 sub-sections to improve readability. Updated CMTS and CM state machines. 
Added a example transaction diagram. 

DCC General Operation 

• Added a MUST for CM operation to the end of the first paragraph. 

• Removed "If the CM has previously established ranging on the new channel, and if that ranging on 
that channel is still current (T 4 has not elapsed since the last successful ranging), then the CM MAY 
use cached ranging information and omit re-ranging." per Andrews suggestion. It was a lay-over 
from UCC. Plus, it was not being shown in the state machine 

• Removed ''The CM SHOULD cache UCD information from multiple upstream channels to eliminate 
waiting for a UCD corresponding to the new upstream channel." Another lay-over from UCC. The 
DCC command explicitly states how to treat UCD messages. 

DCC Exception Conditions 

• Added a note that the retries of DCC-REQ must be done on the old and new downstream channel. 

• Added a note that if the CM fails on the new channel, it will return to the old channel assignment 
and re-initialize. 

• Added a note that stated clearly that the CM must not act on duplicate DCC-REQ commands and 
respond with a DCC-RSR 

Seamless Operation 

• Added a note that in order to provide seamless operation, the CMTS will have to duplicate the 
downstream packet on both the old and new channels during change-over. 

• Added an explicit list of MUST conditions. 
Example Operation 

• Describes interaction with other MAC messages. 
• Appendix B: 

• Removed Tl 1 and T12 (these were added in rev 0.6). T5 is now used exclusively. 



Update on Rev 0.8, 2/27/00 

This update is based upon review comments received from the DOCSIS 1 . 1 group on 2/22/00. 

• Added a preface section which details required changes elsewhere in the 103 document 

• Noted updated needed to Figure 6- 1 7 

• 6.3.20 DCC-REQ 

• Added Transaction ID. 

• Expanded Downstream parameters 

• Combined ranging TLV and configure TLV into one Initialization TLV 

• Removed SFID TLV. 

• 6.3.21 DCC-RSP 

• Added Transaction ID and Confirmation Code 

• DCC is now on old channel and new channel 

• 6.3.22 DCC-ACK 

• New message. 
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• 9.4.5.1 DCC General Operation 

• Clarified that downstream ID and upstream ID must be unique. 

• Updated flow diagram and all state machines. 

• Appendix B 

• Redid the timers. Now Til, T12, T13, T14 

• Appendix C,4 

• Changed rejection code. 

• Appendix H 

• Clarified that operation is single channel. 



Update on Rev 0.90, 2/28/00 

This update is based upon review comments received fi^om the DOCSIS 1 . 1 group on 2/28/00. 

• Renumbered section 9.3.4 to 9.4.5 

• 6.3.20 DCC-REQ 

• Added a SYNC Substitution TLV. This will potentially shave an additional 200 ms off of the 
change-over time. 

• 9.5,4.1 DCC Operation 

• Added a paragraph explaining that DCC-RSP does not gate QoS resources. 

• 9.4.5.2 DCC Exceptions 

• Added a paragraph explaining T14. 

• 9.4.5.3 Seamless Channel Change 

• Changed all MUSTs to SHOULDs 

• Added a CM SHOULD section 

• Added the concept of caching MAPs. This will shave an additional 5-20 ms off of the change-over 
time. 

• Updated flow diagram and state machines. 



Update on Rev 0.91, 3/2/00 

This update is prior to the review meeting of March 3, 2000 

• 6.3.20 DCC-REQ 

• Added SFID Substitution ID TLV back in. 

• Added Classifier ID Substitution TLV 

• Added PHSI Substitution TLV 

• Figures 

• Figure 9-21, CM SM part 2 was down-rev. Update inserted. 
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Update on Rev 0.92, 3/3/00 

These changes are a result of the DOCSIS 1.1 review meeting that took place on 3/3/00. 

• 6.3.20 DCC-REQ 

• Added HMAC digest 

• Added downstream channel ID to downstream parameters TLV 

• Combined SID, Classifier ID, and PHSI into sub-TLVs under Service Flow ID. 

• Added Grant-Sync TLV per ECN-RFI-00009. 

• Fixed type in Interleaver dept. J parameter was missing. 
<» 6.3.21 DCC-RSP 

• Added HMAC digest 

• Changed figure to allow TLV field. 

• Added a reject-already- there(4) and reserved(5-255) 

• 6.2.22 DCC-ACK 

• Added HMAC digest 

• 9.4.5.2 DCC Exception Conditions 

• Added a sentence covering glare situation of CM had a DSx-ACK outstanding. This should also 
cover the case where a CM might do multiple independent and overlapping DSx commands. 

• 9.4.5.3 Near-Seamless Channel Change 

• Renamed from Seamless to Near-Seamless to be more accurate with the name and less binding. 

• Added notes to specify Grant Timing 

• Added a sentence alerting applications that packets may still get dropped in both directions. 

• Figures 

• Renamed "leaving" to "depart" and "arrived" to "arrive" 

• If CM is already using the channels specified in DCC-REQ, the CM returns a reject message. The 
state diagrams make a distinction between different reject error codes 



Update on Rev 0.93, 3/8/00 

Mainly grammar updates and clarifications. 
Got 2/3 of the way through Clive's comments. 
This revision was released as an ECO update. 
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Update on Rev 0,94, 3/9/00 
Finished Clive's comments. Added some from Mike St John and Lisa. 
Mainly more grammar and clarifications. 

One new item added regarding adding a CM Jump Time TLV to DCC-RSP 

• 6.3.20.1.5 SYNC Substitution 

• Added operational note about faster SYNCs. 

• 6.3.21 DCC-RSP 

• Moved error codes to Appendix C.4.2 to be consistent with RFI-o-000 1 7. 

» Dropped reject-temporary and reject-permanent and pointed to C.4 codes instead 

• Allow any C.4 code to be used if it is appropriate. 

• 9.4.5.3 Example Operation 

• Clarified CMTS INIT bullet 

• Added CMTS SYNC bullet. 

• Add a operational note to the CMTS MAP bullet 



Update on Rev 0.95, 3/10/00 



The state transition diagrams were not working out for the CM due to the multiple conditional statements, so they 
have not been included. 

• 6.3.20.1.7.5 Unsolicited Grant Synchronization Time 

• Removed current sync time from the TLV. 

• 9.4.5.3 Near-Seamless Channel Change 

• Moved the "SHOULDs" which were not directly testable and not directly related to the CMTS to a 
separate bullet list and listed as "shoulds" 

• Added a comment regarding SCN usage to "shoulds" list. 

• Figures 

• Changed "DCC-RSP (reject-temp/perm)" to "DCC-RSP (<reject-reason>)" 

• Updated Appendix H figures with SCTE standard symbols. 

Outstanding Issues: 

• none 
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Update on Rev 0.96, 3/14/00 

From some e-mail review comments. 

• 6.3.20.1 Encodings 

• Added a comment indicating that not other parameters may change except the ones Usted here. 

• 6.3.20.1.2.5 Downstream Channel Identifler 

• Added a comment indicating that the downstream channel identifier was unique. 

• 6.3.20.1.3 Initialization Technique 

• Added a comment indicating the ranging is done with the primary SID and that the primary SID 
may be substituted. 

• 6.3.20.1.5 SYNC Substitution 

• Added a comment clarify that synced timestamps are timestamps with the same clock and the same 
value. 

• 9.4.5.2 DCC Exception Conditions 

• Added a phase indicating that the DCC transaction must complete before the CM redoes the DSA. 

• 9.5.4.3 Near Seamless Channel Change 

• Changed wording to indicate the CMTS should use the same timestamp on both channels. 

• Moved wording regarding CM IP addresses. 

• 9.4.5.4 Example Operation 

• CM: SYNC and UCD where out of sequence 

• CM: Added a bullet for the MAR 

Update on Rev 0.97, 3/2200 

• 6.3.6.3 Overriding Channels During Initial Ranging 

• Added DCC-REQ reference to a paragraph that made reference to UCC. 

• 6.3.20.1 DCC-REQ Encodings 

• Added explicit MUST/SHOULD/MAY tags to each encoding. The format looks like: "The CMTS 
MUST/SHOULD/MAY include this TLV. The CM MUST/SHOULD/MAY observe this TLV\ 

• I used MUST for TLVs that were needed to make the basics work; SHOULD for TLVs which 
enhanced performance; and MAYs for TLV which affected logical operation but where application 
dependent. 

• 6.3.20.1.4 UCD Substitution 

• Changed the grammar to singular from plural. Added "This TLV occurs once and contains one 
UCD" to introduction section. 

• 6.3.2L1 DCC-RSP Encodings 

• Added explicit MUST/SHOULD for CM. 

• 9.4.5.1 DCC General Operation 

• Clarified that T13 does not include any re-init time. 

• 9.4.5.3 Near Seamless Channel Change 

• Added bullet stating CM SHOULD include Jump Time. 

• H.2.2 Normal Operation 

• Added RNG-RSP and DCC-REQ to Table H- 1 
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Update on Rev 0.98, 3/28/00 

DCC was changed from a MUST to MAY for both CMTS and CM. 

• 6.3.20 DCC-REQ 

• Add the adjective "DCC-capable" to CM 

• 6.3.21 DCC-RSP 

• Add to the first paragraph the phrase "A CM MAY support Dynamic Channel Change, If the CM 
supports Dynamic Channel Change, .... " 

• 9.4.5.1 General Operation 

• Add the adjective "DCC-capable" to CM 

• C.1.3.1.12 DCC Support 

• Added a modem capabihty bit for DCC 



Update on Rev 0.99, 5/30/00 



• Incorporated RFI-N-00029 into Appendix H. For consistancy with the surrounding paragraphs, 

• "response" was changed to "Ranging Response" 

• "range response" was changed to "Ranging Response" 

• "range request" was changed to "Ranging Request" 

• "ranging-response" was changed to "Ranging Response" 



§t2 S upport for Mu l t i ple Channolo 

Figaro 6 28. 
UpGiroam Channoi DoGoriptor (UCD) 
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Revisions Required to other Areas of DOCSIS L 1 to support this proposal 



• 6.3,1 MAC Management Message Header 

Table 6-17, page 91. Add the following message types 23 to 25 and modify comments for message types 
26-255. 



Type Value 


Version 


Message Name 


Message Description 


23 


2 


DCC-REQ 


Dynamic Channel Change Request 


24 


2 


DCC-RSP 


Dynamic Channel Change Response 


25 


2 


DCC-ACK 


Dynamic Channel Change Acknowledge 


26-255 






Reserved for future use 



• 6.3.6.3 Overriding Channels During Initial Ranging 

Change the last sentence of the last paragraph from: 

"Once ranging is complete, only the C. 1 . 1 .2 and UCC-REQ mechanisms are available for moving the 
modem to a new upstream channel, and only the C. 1 . 1 . 1 mechanism is available for moving the modem 
to a new downstream channel." 

to: 

"Once ranging is complete, only the C. 1.1,2, UCC-REQ, and DCC-REQ mechanisms are available for 
moving the modem to a new upstream channel, and only the C. 1 . 1 . 1 mechanism and DCC-REQ is 
available for moving the modem to a new downstream channel." 

• 6.3.10 Upstream Channel Change Request (UCC-REQ) 

Change the footnote on page 94 of 103 from: 

" This value authorizes a CM to use an initial maintenance or station maintenance region, which ever 
occurs first. This value might be used when there is uncertainty when the CM may execute the UCC and 
thus a chance that it might miss station maintenance slots." 

to: 

" This value authorizes a CM to use an initial maintenance or station maintenance region, which ever 
the CM selects. This value might be used when there is uncertainty when the CM may execute the UCC 
and thus a chance that it might miss station maintenance slots. 

The footnote as stated creates a hardware incompatibility. This was noticed during one of the DCC 
review cycles. 
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6.3.20 Dynamic Channel Change Request (DCC-REQ) 

A Dynamic Channel Change Request MAY be transmitted by a CMTS to cause a DCC-capable CM to change 
the upstream channel on which it is transmitting, the downstream channel it is receiving, or both. 



Bit 0 



16 



24 



31 



MAC Management Message Header 



Transaction ID 



TLV Encoded 
Information 



Figure 6-29. Dynamic Channel Change Request 

A CMTS MUST generate DCC-REQ message in the form shown in Figure 6-29 including the following 
parameter; 

Transaction ID A 16 bit unique identifier for this transaction assigned by the sender.; 

The following parameters are optional and are coded as TLV tuples. 
Upstream Channel ID 



Downstream Parameters 



Initialization Technique 



UCD Substitution 



SAID Substitution 



Service Flow Substitution 



The identifier of the upstream channel to which the CM is to switch for 
upstream transmissions. 

The frequency of the downstream channel to which the CM is to switch for 
downstream reception. 

Directions for the type of initialization, if any, that the CM should perform 
once synchronized to the new channel(s). 

Provides a copy of the UCD for the new channel. This TLV occurs once and 
contains one UCD. 

A pair of Security Association Identifiers (SAID) which contain the current 
SAID and the new SAID for the new channel. This TLV occurs once if the 
SAID requires substitution. 

A group of sub-TLVs which allows substitution in a Service Flow of the 
Service Flow Identifier, Service Identifier, Classifier Identifier, and the 
Payload Header Suppression Index. This TLV is repeated for every Service 
Flow which has parameters requiring substitution. 
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If Privacy is enabled, a DCC-REQ MUST also contain: 

HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the 

sender). The HMAC-Digest Attribute MUST be the final Attribute in the 
Dynamic Channel Change message's Attribute list. (Refer to Appendix 
Appendix C. 1.4.1) 

6.3.20.1 Encodings 

The type values used MUST be those shown below. These are unique within the Dynamic Channel Change 
Request message, but not across the entire MAC message set. 

If a CM performs a channel change without performing a re-initialization (as defined in Section ), then all the 
configuration variables of the CM MUST remain constant, with the exception of the configuration variables 
which are explicitly changed below. The CM will not be aware of any configuration changes other than the ones 
that have been supplied in the DCC command, so consistency in provisioning between the old and new channels 
is important. 

6,3.20,1.1 Upstream Channel ID 

When present, this TLV specifies the new upstream channel ID that the CM MUST use when performing a 
Dynamic Channel Change. It is an override for the current upstream channel ID, The CMTS MUST ensure that 
the Upstream Channel ID for the new channel is different than the Upstream Channel ID for the old channel. 
This TLV MUST be included if the upstream channel is changed, even if the UCD substitution TLV is included. 

Type Length Value 

1 1 0-255: Upstream Channel ID 



If this TLV is missing, the CM MUST NOT change its upstream channel ID. The CMTS MAY include this TLV 
The CM MUST observe this TLV. 

6, 3,20, 1, 2 Downstream Parameters 

When present, this TLV specifies the operating parameters of the new downstream channel. The value field of 
this TLV contain a series of sub-types. The CMTS MUST include all sub-types. 

Type Length Value 
2 n 

If this TLV is missing, the CM MUST NOT change its downstream parameters. 
6, 5. 20, 1, 2, 1 Downstream Frequency 

This TLV specifies the new receive frequency that the CM MUST use when performing a Dynamic Channel 
Change. It is an override for the current downstream channel frequency. This is the center fi*equency of the 
downstream channel in Hz and is stored as a 32-bit binary number. The downstream frequency MUST be a 
multiple of 62,500 Hz. 

Subtype Length Value 

2.1 4 Rx Frequency 
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The CMTS MUST include this sub-TLV. The CM MUST observe this sub-TLV. 



6.3.20.1.2.2 Downstream Modulation Type 

This TLV specifies the modulation type that is used on the new downstream channel. 

Subtype Length Value 

2.2 10 = 64 QAM 

1 = 256 QAM 
2- 255: reserved 

The CMTS SHOULD include this sub-TLV. The CM SHOULD observe this sub-TLV. 

6. 3. 20. 1. 2. 3 Downstream Symbol Rate 

This TLV specifies the symbol rate that is used on the new downstream channel. 

Subtype Length Value 

2.3 1 0 = 5.056941 Msym/sec 

1 = 5.360537 Msym/sec 

2 = 6.952 Msym/sec 

3 - 255: reserved 

The CMTS SHOULD include this sub-TLV The CM SHOULD observe this sub-TLV 

6. 3.20. 1. 2. 4 Downstream Interleaver Depth 

This TLV specifies the parameters "F* and J of the downstream interleaver. 

Subtype Length Value 

2.4 2 L 0-255 

J: 0-255 

The CMTS SHOULD include this sub-TLV. The CM SHOULD observe this sub-TLV 

6.3.20.1.2.5 Downstream Channelldentijier 

This TLV specifies the 8 bit downstream channel identifier of the new downstream channel. The CMTS MUST 
ensure that the Downstream Channel ID for the new channel is different than the Downstream Channel ID for the 
old channel. 

Subtype Length Value 

2.5 1 0-255: Downstream Channel ID. 

The CMTS SHOULD include this sub-TLV. The CM SHOULD observe this sub-TLV 

6.3,20,1,3 Initialization Technique 

When present, this TLV allows the CMTS to direct the CM as to what level of re-initialization, if any, it MUST 
perform before it can commence communications on the new channel(s). The CMTS can make this decision 
based upon its knowledge of the differences between the old and new MAC domains and the PHY characteristics 
of their upstream and downstream channels. 
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Typically, if the move is between upstream and/or downstream channels within the same MAC domain, then the 
connection profile values may be left intact. If the move is between different MAC domains, then a complete 
initialization may be performed. 

If a complete re-initialization is not required, some re-ranging may still be required. For example, areas of 
upstream spectrum are often configured in groups. A DCC-REQ to an adjacent upstream channel within a group 
may not warrant re-ranging. Alternatively, a DCC-REQ to a non-adjacent upstream channel might require station 
maintenance whereas a DCC-REQ from one upstream channel group to another might require initial 
maintenance. Re-ranging may also be required if there is any difference in the PHY parameters between the old 
and new channels. 

Type Length Value 

3 1 0 = Reinitialize the MAC 

1 = Perform initial maintenance on new channel before normal operation. 

2 = Perform station maintenance on new channel before normal operation. 

3 = Perform either initial maintenance or station maintenance on new channel before 

normal operation. 

4 = Use the new channel(s) directly without re-initializing or performing initial or 

station maintenance 

5 - 255: reserved 

The CM MUST first select the new upstream and downstream channels based upon the Upstream Channel ID 
TLV (refer to Section 6.3.20. 1 . 1) and the Downstream Frequency TLV (refer to Section 6.3.20. 1 .2. 1). Then the 
CM MUST follow the directives of this TLV. For option 0, the CM MUST begin with the Initialization SID. For 
options 1 to 4 the CM MUST continue to use the primary SID for ranging. A SID Substitution TLV (see Section 
6.3.2 1 . 1 .7.2) may specify a new primary SID for use on the new channel (refer to Section ). 

Option 0: This option directs the CM to perform all the operations associated with initializing the CM 
(refer to Section 9.2). This includes all the events after acquiring downstream QAM, FEC, and 
MPEG lock and before Standard Operation (refer to Section 9.3), including obtaining a UCD, 
ranging, establishing IP connectivity, establishing time of day, transfer of operational 
parameters, registration, and baseline privacy initialization. When this option is used, the only 
other TLVs in DCC-REQ that are relevant are the Upstream Channel ID TLV and the 
Downstream Parameters TLV All other DCC-REQ TLVs are irrelevant. 

Option 1: If initial maintenance is specified, operation on the new channel could be delayed by several 
Ranging Intervals (see Appendix B). 

Option 2: If station maintenance is specified, operation on the new channel could be delayed by the value 
of T4 (see Appendix B). 

Option 3: This value authorizes a CM to use an initial maintenance or station maintenance region, which 
ever the CM selects. This value might be used when there is uncertainty when the CM may ex- 
ecute the DCC command and thus a chance that it might miss station maintenance slots. 

Option 4: This option provides for the least interruption of service, and the CM may continue its normal 
operation as soon as it has achieved synchronization on the new channel. This option is 
intended for use with a near-seamless channel change (refer to Section 9.4.5.3). 

Note: This option should not be used in physical plants where upstream transmission characteristics are 
not consistent. 

If this TLV is absent, the CM MUST re-initialize the MAC. The CMTS MAY include this TLV. The CM MUST 
observe this TLV. 
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6.3.20.1.4 UCD Substitution 

When present, this TLV allows the CMTS to send an Upstream Channel Descriptor message to the CM. This 
UCD message is intended to be associated with the new upstream and/or downstream channel(s). The CM stores 
this UCD messages in its cache, and uses it after synchronizing to the new channel(s). 

Type Length Value 

4 n UCD for the new upstream channel 

This TLV includes all parameters for the UCD message as described in section Section 6.3.3 except for the MAC 
Management Message Header. The CMTS MUST ensure that the change count in the UCD matches the change 
count in the UCDs of the new channel(s). The CMTS MUST ensure that the Upstream Channel ID for the new 
channel is different than the Upstream Channel ID for the old channel. 

If the CM has to wait for a new UCD message when changing channels, then operation may be suspended for a 
time up to the "UCD Interval" (see Appendix B) or longer, if the UCD message is lost. 

The CMTS SHOULD include this TLV. The CM SHOULD observe this TLV. 

6.3.20.1.5 SYNC Substitution 

When present, this TLV allows the CMTS to inform the CM to wait or not wait for a SYNC message before 
proceeding. The CMTS MUST have synchronized timestamps between the old and new channel(s) if it instructs 
the CM to not wait for a SYNC message before transmitting on the new channel. Synchronized timestamps 
implies that the timestamps are derived from the same clock and contain the same value. 

Type Length Value 

5 1 0 = acquire SYNC message on the new downstream channel before proceeding 

1 = proceed without first obtaining the SYNC message 
2- 255: reserved 



If this TLV is absent, the CM MUST wait for a SYNC message on the new channel before proceeding. If the CM 
has to wait for a new SYNC message when changing channels, then operation may be suspended for a time up to 
the "SYNC Interval" (see Appendix B) or longer, if the SYNC message is lost or is not synchronized with the old 
channel(s). 

An alternative approach is to send SYNC messages more frequently (every 10 ms for example), and continue to 
require the CM to wait for a SYNC message before proceeding. This approach has the slightly more latency, but 
provides an additional check to prevent the CM from transmitting at an incorrect time interval. 

The CMTS SHOULD include this TLV. The CM SHOULD observe this TLV 
63.20.1.6 Security Association Identifier (SAID) Substitution 

When present, this TLV allows the CMTS to replace the Security Association Identifier (SAID) in the current 
Service Flow with a new Security Association Identifier. The baseline privacy keys associated with the SAID 
MUST remain the same. The CM does not have to simultaneously respond to the old and new SAID. 

Type Length Value 

6 4 current SAID (lower order 14 bits of a 16 bits field), 

new SAID (lower order 14 bits of a 16 bit field) 
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If this TLV is absent, the current Security Association Identifier assignment is retained. The CMTS MAY include 
this TLV. The CM MUST observe this TLV. 

6, 3,20, L 7 Service Flow Substitutions 

When present, this TLV allows the CMTS to replace specific parameters within the current Service Flows on the 
current channel assignment with new parameters for the new channel assignment. One TLV is used for each 
Service Flow that requires changes in parameters. The CMTS MAY choose to do this to help facilitate setting up 
new QoS reservations on the new channel before deleting QoS reservations on the old channel. The CM does not 
have to simultaneously respond to the old and new Service Flows. 

This TLV allows resource assignments and services to be moved between two independent ID value spaces and 
scheduling entities by changing the associated IDs and indexes. ID value spaces that may differ between the two 
channels include the Service Flow Identifier, the Service ID, the Classifier Identifier, and the Payload Header 
Suppression Index. This TLV does not allow changes to Service Flow QoS parameters, classifier parameters, or 
PHS rule parameters. 

The Service Class Names used within the Service Flow ID should remain identical between the old and new 
channels. 

Type Length Value 

7 n list of subtypes 

If this TLV is absent for a particular Service Flow, then current Service Flow and its attributes are retained. The 
CMTS MAY include this TLV The CM MUST observe this TLV 

6.3.20.1. 7.1 Service Flow Identifier Substitution 

This TLV allows the CMTS to replace the current Service Flow Identifier (SFID) with a new Service Flow 
Identifier. Refer to Appendix C.2.2.3.2 for details on the usage of this parameter. 

This TLV MUST be present if any other Service Flow subtype substitutions are made. If this TLV is included and 
the Service Flow ID is not changing, then the current and new Service Flow ID will be set to the same value. 

Subtype Length Value 

7.1 8 current Service Flow ID, new Service Flow ID 
The CMTS MAY include this TLV. The CM MUST observe this TLV 

6.3.20.1. 7.2 Service Identifier Substitution 

When present, this TLV allows the CMTS to replace the Service Identifier (SID) in the current upstream Service 
Flow with a new Service Identifier. Refer to Appendix C.2.2.3.3 for details on the usage of this parameter. 

Subtype Length Value 

7.2 4 current SID (lower order 14 bits of a 1 6 bits field), 

new SID (lower order 14 bits of a 16 bits field) 

If this TLV is absent, the current Service Identifier assignments are retained. The CMTS MAY include this TLV 
The CM MUST observe this TLV. 
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6.3J0.L Z3 Classifier ID Substitution 

When present, this TLV allows the CMTS to replace the the current Classifier Identifier with a new Classifier 
Identifier. One TLV is used for each pair of old and new Classifier Identifier that are to be substituted within this 
Service Flow. Refer to Appendix C. 2. 1 .3.2 for details on the usage of this parameter. 

Subtype Length Value 

7.3 4 current Classifier ID, new Classifier ID 

If this TLV is absent, the current Classifier Identifier is retained. The CMTS MAY include this TLV. The CM 
MUST observe this TLV 

6, 3, 20, L 7. 4 Pay load Header Suppression Index Substitution 

When present, this TLV allows the CMTS to replace the current Payload Header Suppression Index (PHSI) with 
a new Payload Header Suppression Index. Refer to Appendix C.2.2.10.2 for details on the usage of this 
parameter. 

Subtype Length Value 

7.4 2 current PHSI, new PHSI 

If this TLV is absent, the current Payload Header Suppression Index is retained. The CMTS MAY include this 
TLV. The CM MUST observe this TLV. 

6. 5. 20, 1. 7. 5 Unsolicited Grant Time Reference Substitution 

When present, this TLV allows the CMTS to replace the current Unsolicited Grant Time Reference with a new 
Unsolicited Grant Time Reference. Refer to Appendix C.2.2.6.1 1 for details on the usage of this parameter. 

This TLV is useful if the old and new upstream use different time bases for their time stamps. This TLV is also 
usefiil if the Unsolicited Grant transmission window is moved to a different point in time. Changing this value 
may cause operation to temporarily exceed the jitter window specified by Appendix C.2.2.6.8. 

Subtype Length Value 

7.5 4 new reference 

If this TLV is absent, the current Unsolicited Grant Time Reference is retained. The CMTS MAY include this 
TLV. The CM MUST observe this TLV 
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6.3.21 Dynamic Channel Change - Response (DCC-RSP) 

A CM MAY support Dynamic Channel Change. If the CM supports Dynamic Channel Change, a Dynamic 
Channel Change Response MUST be transmitted by a CM in response to a received Dynamic Channel Change 
Request message to indicate that it has received and is complying with the DCC-REQ. The format of a DCC- 
RSP message MUST be as shown in Figure 6-30. 

Before it begins to switch to a new upstream or downstream channel, a CM MUST transmit a DCC-RSP on its 
existing upstream channel. When a CM receives a DCC-REQ message requesting that it switch to an upstream 
and/or downstream channel that it is already using, the CM MUST respond with a DCC-RSP message on that 
channel indicating that it is already using the correct channel. 

A CM MAY ignore a DCC-REQ message while it is in the process of performing a channel change. 

After switching to a new channel, if the MAC was not re-initialized per DCC-REQ Initialization TLV, option 0, 
the CM MUST send a DCC-RSP message to the CMTS. A DCC-RSP MUST NOT be sent if the CM reinitializes 
its MAC. 

The full procedure for changing channels is described in Section 9.4.5. 



Bit 0 
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Figure 6-30. Dynamic Channel Change Response 



Parameters MUST be as follows: 

Transaction ID A 16 bit Transaction ID from corresponding DCC-REQ. 

Confirmation Code An 8 bit Confirmation Code as described in Appendix C.4. 1 

The following parameters are optional and are coded as TLV tuples. 

CM Jump Time Timing parameters describing when the CM will make the jump. 

Regardless of success or failure, if Privacy is enabled for the CM the DCC-RSP MUST contain: 
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HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the 

sender). The HMAC-Digest Attribute MUST be the final Attribute in the 
Dynamic Channel Change message's Attribute list. (Refer to Appendix 
C.1.4.1) 

6.3.21.1 Encodings 

The type values used MUST be those shown below. These are unique within the Dynamic Channel Change 
Response message, but not across the entire MAC message set. 

6.3.2LL1 CM Jump Time 

When present, this TLV allows the CM to indicate to the CMTS when the CM plans to perform its jump and be 
disconnected from the network. With this information, the CMTS MAY take preventative measures to minimize 
or to eliminate packet drops in the downstream due to the channel change. 

Type Length Value 

1 n 

The time reference and units of time for these sub-TLVs is based upon the same 32 bit time base used in the 
SYNC message on the current downstream channel. This timestamp is incremented by a 10.24 MHz clock 

The CM SHOULD include this TLV. The CMTS SHOULD observe this TLV. 
6, 3, 21, L 1, 1 Length of Jump 

This TLV indicates to the CMTS the length of the jump from the previous channel to the new channel. 
Specifically, it represents the length of time that the CM will not be able to receive data in the downstream. 

Subtype Length Value 

1 4 length (based upon timestamp) 
The CM MUST include this sub-TLV 

6J,2LLL2 Start Time of Jump 

When present, this TLV indicates to the CMTS the time in the future that the CM is planning on making the 
jump. 

Subtype Length Value 

2 8 start time (based upon timestamp), 

accuracy of start time (based upon timestamp) 

The 32 bit, 10.24 MHz time base rolls over approximately every 7 minutes. If the value of the start time is less 
than the the current timestamp, the CMTS will assume one roll-over of the timestamp counter has elapsed. The 
accuracy of the start time is an absolute amount of time before and after the start time. 

The potential jump window is from (start time - accuracy) to (start time + accuracy + length). 

The CM SHOULD include this TLV 
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6.3.22 Dynamic Channel Change -- Acknowledge (DCC-ACK) 

A Dynamic Channel Change Acknowledge MUST be transmitted by a CMTS in response to a received Dynamic 
Channel Change Response message on the new channel with its Confirmation Code set to arrive(l). The format 
of a DCC-ACK message MUST be as shown in Figure 6-3 1 . 



Bit 0 8 16 24 31 



MAC Management Message Header 



Transaction ID 



TLV Encoded 
Information 



Figure 6-31. Dynamic Channel Change Acknowledge 

Parameters MUST be as follows: 

Transaction ID A 16 bit Transaction ID from corresponding DCC-RSR 

If Privacy is enabled, the DCC-ACK message MUST contain: 

HMAC-Digest The HMAC-Digest Attribute is a keyed message digest (to authenticate the 

sender). The HMAC-Digest Attribute MUST be the final Attribute in the 
Dynamic Channel Change message's Attribute list. (Refer to Appendix 
Appendix C. 1.4.1) 
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9 Cable Modem - CMTS Interaction 
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9.4.5 Dynamically Changing Downstream and/or Upstream Channels 
9.4.5.1 DCC General Operation 

At any time after registration, the CMTS MAY direct the CM to change its downstream and/or upstream channel. 
This may be done for traffic balancing, noise avoidance, or other reasons which are beyond the scope of this 
specification. Figure 9-18 shows the procedure that MUST be followed by the CMTS. Figure 9-20 shows the 
corresponding procedure that MUST be followed by a DCC-capable CM. 

The DCC command can be used to change only the upstream frequency, only the downstream fi-equency, or both 
the upstream and downstream frequencies. When only the upstream or only the downstream frequency is 
changed, the change is typically within a MAC domain. When both the upstream and downstream frequencies 
are changed, the change may be within a MAC domain, or between MAC domains. 

The Downstream Channel ID and the Upstream Channel ID MUST both be unique between the old and new 
channels. In this context, the old channel refers to the channel(s) that the CM was on before the jump, and the 
new channel refers to the channel(s) that the CM is on after the jump. 

Upon synchronizing with the new upstream and/or downstream channel, the CM MUST use the technique 
specified in the DCC-REQ Initialization Technique TLV, if present, to determine if it should perform re- 
initialization, only ranging, or neither. If this TLV is not present in DCC-REQ, the CM MUST re-initialize its 
MAC on the new channel assignment. (Refer to Section ). If the CM has been instructed to re-initialize, then the 
CMTS MUST NOT wait for a DCC-RSP to occur on the new channel. 

If the CM is being moved within a MAC domain, then a re-initialization may not be required. If the CM is being 
moved between MAC domains, then a re-initialization may be required. Re- initializing, if requested, is done 
with the new upstream and channel assignments. It includes obtaining upstream parameters, establish IP 
connectivity, establish time of day, transfer operational parameters, register, and initialize baseline privacy. If re- 
initialization is performed, the CM MUST NOT send a DCC-RSP on the new channel. 

The decision to re-range is based upon the CMTS's knowledge of any path diversity that may exist between the 
old and new charmels, or if any of the fundamental parameters of the upstream or downstream channel such as 
symbol rate, modulation type, or minislot size have changed. 

When DCC-REQ does not involve re-initialization or re-ranging, the design goal of the CM will typically be to 
minimize the disruption of traffic to the end user. To achieve this goal, a CM MAY choose to continue to use QoS 
resources (such as bandwidth grants) on its current channel after receiving a DCC-REQ and before actually 
executing the channel change. The CM might also need this time to flush internal queues or reset state machines 
prior to changing channels. 
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The CM MAY continue to use QoS resources on the old channel, including the transmission and reception of 
packets, after sending a DCC-RSP (depart) message and prior to the actual jump. The CM MAY use QoS 
resources on the new channel, including the transmission and reception of packets, after the jump and prior to 
sending a DCC-RSP (arrive) message. The CMTS MUST NOT use the DCC-RSP (depart) message to remove 
QoS resources on the old channel. The CMTS MUST NOT wait for a DCC-RSP (arrive) message on the new 
channel before allowing QoS resources to be used. This provision is to allow the Unsolicited Grant Service to be 
used on the old and new channel with a minimum amount of disruption when changing channels. 

The CMTS MUST hold the QoS resources on the current channel until a time of T13 has passed after the last 
DCC-REQ that was sent, or until it can internally confirm the presence of the CM on the new channel 
assignment. The CM MUST execute the departure from the old channel and arriving at the new channel, less any 
commanded re-initialization, before the expiry of T13. The CM MAY continue to use QoS resources on the 
current channel after responding with DCC-RSP and before the expiry of T13. 

Once the CM changes channels, all previous outstanding bandwidth requests made via the Request IE or 
Request/Data IE are invalidated, and the CM MUST re-request bandwidth on the new channel. In the case of 
Unsolicited Grant Service in the upstream, the grants are implicit with the QoS reservations, and do not need to 
be re-requested. 

9.4.5.2 DCC Exception Conditions 

If a CM issues a DSA-REQ or DSC-REQ for more resources, and the CMTS needs to do a DCC to obtain those 
resources, the CMTS will reject the DSA or DSC command without allocating any resources to the CM. The 
CMTS includes a confirmation code of "reject-temporary-DCC" (refer to Appendix C. 1.3,1) in the DSC-RSP 
message to indicate that the new resources will not be available until a DCC is received. The CMTS will then 
follow the DSA or DSC transaction with a DCC transaction. 

After the CM jumps to a new channel and completes the DCC transaction, the CM retries the DSA or DSC 
command. If the CM has not changed channels after the expiry of T14, as measured firom the time that the CM 
received DSA-RSP or DSC-RSP fi-om the CMTS, then the CM MAY retry the resource request. 

If the CMTS needs to change channels in order to satisfy a resource request other than a CM initiated DSA or 
DSC command, then the CMTS should execute the DCC command first, and then issue a DSA or DSC 
command. 

If a CMTS does a DCC with re-initialize, the config file could cause the CM to come back to the original 
channel. This would cause an infinite loop. To prevent this, if the provisioning system default is to specify the 
upstream channel ID and/or the downstream frequency, then the CMTS SHOULD NOT use DCC-REQ with the 
re-initialize option. 

The CMTS MUST NOT issue a DCC command if the CMTS has previously issued a DSA, or DSC command, 
and that command is still outstanding. The CMTS MUST NOT issue a DCC command if the CMTS is still 
waiting for a DSA-ACK or DSC-ACK from a previous CM initiated DSA-REQ or DSC-REQ command. 

The CMTS MUST NOT issue a DSA or DSC command if the CMTS has previously issued a DCC command, 
and that command is still outstanding. 

If the CMTS issues a DCC-REQ command and the CM simultaneously issues a DSA-REQ or DSC-REQ then 
the CMTS command takes priority. The CMTS responds with a confirmation code of "reject- temporary" (refer to 
Appendix C, 1 .3. 1). The CM proceeds with executing the DCC command. 
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If the CM is unable to achieve communications with a CMTS on the new channel(s), it MUST return to the 
previous channel(s) and re-initiahze its MAC. The previous channel assignment represents a known good 
operating point which should speed up the re-initialization process. Also, returning to the previous channel 
provides a more robust operational environment for the CMTS to fmd a CM that fails to connect on the new 
channel(s). 

If the CMTS sends a DCC-REQ and does not receive a DCC-RSP within time Tl 1, it MUST retransmit the 
DCC-REQ up to a maximum of "DCC-REQ Retries" (Appendix B) before declaring the transaction a failure. 
Note that if the DCC-RSP was lost in transit and the CMTS retries the DCC-REQ, the CM may have already 
changed downstream channels. 

If the CM sends a DCC-RSP on the new channel and does not receive a DCC-ACK from the CMTS within time 
T12, it MUST retry the DCC-RSP up to a maximum of "DCC-ACK Retries" (Appendix B). 

If the CM receives a DCC-REQ with the Upstream Channel ID TLV, if present, equal to the current Upstream 
Channel ID, and the Downstream Frequency TLV, if present, is equal to the current downstream frequency, then 
the CM MUST consider the DCC-REQ as a redundant command. The remaining DCC-REQ TLV parameters 
MUST NOT be executed, and the CM MUST return a DCC-RSP, with a confirmation code of "reject-already- 
there", to the CMTS (refer to Appendix C.4.1). 

9.4.5.3 Near-Seamless Channel Change 

When the CMTS wishes to add new QoS reservations to a CM, it may be necessary to move that CM to a new 
upstream and/or downsteam to achieve that goal. During that changing of channels, it is desirable to provide the 
minimum of interruption to existing QoS services such as voice over IP or video streaming sessions. This near- 
seamless channel change is the primary design goal of the DCC command. The CMTS MAY support a near- 
seamless channel change. The CM MAY support a near-seamless channel change. 

The actions below are recommended operating procedures to implement a near-seamless channel change. The 
list assumes both the upstream and dovrastream channels are changing. A subset of the list would apply if only 
the upstream or downstream channel changed. 

To support a near-seamless channel change, the following conditions should apply in the network: 

• The physical layer parameters for the new upstream and downstream channels should not change 
with the old upstream and downstream channels. Note that a change in downstream parameters 
could invalidate the ranging parameters. 

• The ranging parameters should not change between the old and new channels. This may require 
symmetrical cabling and plant conditions which are external to the CMTS. 

• The CMTS should use the same time stamp and SYNC mechanism for all dovmstream channels. 

• IP routing should be configured so that the CM and its attached CPEs can continue to use their existing 
IP addresses. This will avoid disruption to RTP sessions or other in progress applications. 

To achieve a near-seamless channel change, the CMTS: 

• SHOULD duplicate all the relevant QoS reservations for the CM on the old and new channel 
assignments before initiating a DCC-REQ. 

• SHOULD duplicate downstream packet flow for the CM on the old and new channel assignments 
before initiating a DCC-REQ (for downstream channel changes). 

• SHOULD transmit MAP messages for the new upstream channel on the old downstream channel for 
at least the duration of T 13, if the old and new downstream channels share the same timestamp. 
(Note that if the CM cannot cache MAPs for the new upstream while on the old downstream 
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channel, then the channel change delay will be increased by the amount of time into the future that 
MAPS are generated. Thus, the CMTS SHOULD refrain from scheduling MAPs farther into the 
future than it needs to.) 

• SHOULD specify the downstream and upstream parameters of the new channels prior to the CM 
jumping. 

• SHOULD specify to not wait for a SYNC message on the new channel. 

• SHOULD specify to skip initialization (as defined in Section ). 

• SHOULD specify to skip initial maintenance and station maintenance. 

• SHOULD manage service flow substitutions between old and new SIDs, SAID, Service Flow IDs, 
Classifier IDs, Payload Header Suppression Indexes, and Unsolicited Grant Time Reference as 
required. Service Class Names SHOULD remain the same between the old and new channel(s). 



To achieve a near-seamless channel change, the CM: 

• SHOULD reply with estimates for CM Jump Time in the DCC-RSP message. 

• SHOULD listen for and cache MAP messages on the old downstream that apply to the new 
upstream. This SHOULD be done during time T13. 

• SHOULD use the downstream parameters and the UCD in its cache from the DCC command to 
force a quicker PHY convergence when jumping. 

• SHOULD NOT wait for a SYNC message after PHY convergence and before transmitting, if the 
CMTS permits the CM to do so. 

• SHOULD use the cached MAPS, if available, to allow a quicker start-up time. 

• SHOULD minimize the disruption of traffic in either direction by allowing traffic to continue to 
flow in both directions up to the moment prior to the jump and then immediately after 
resynchronization to the new channel(s) has happened. 

• SHOULD queue incoming data packets that arrive during the jump, and transmit them after the 
jump 

• SHOULD discard VoIP packets after the jump that have caused the upstream Unsolicited Grant 
Service queue to exceed its limit, but no more than necessary. 



Applications that are running over the DOCSIS path should be able to cope with the loss of packets that may 
occur during the time that the CM changes channels. 



9.4.5.4 Example Operation 



Figure 9-17 shows an example of the use of DCC and its relation to the other DOCSIS MAC messages. In 
particular, this example describes a scenario where the CM attempts to allocated new resources with a DSA 
message. The CMTS temporarily rejects the request, tells the CM to change channels, and then the CM re- 
requests the resources. This example (not including all exception conditions) is described below. Refer to Section 
9.2 for more detail. 



a) An event occurs, such as the CM issuing a DSA-REQ message. 



b) The CMTS decides that it needs to change channels in order to service this resource request. The CMTS 
responds with a DSA-RSP message which includes a confirmation code of "reject- temporary-DCC" (refer 
to Appendix C.l .3.1) in the DSC-RSP message to indicate that the new resources are not available until a 
DCC is received. The CMTS now rejects any further DSA or DSC messages until the DCC command is 
executed. 
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c) The CMTS initiates QoS reservations on the new upstream and/or downstream channels. The QoS 
reservations include the new resource assignment along with all the current resource assignments assigned 
to the CM. In this example, both the upstream and downstream channels are changed. 

d) To facilitate a near-seamless channel change, since the CMTS is not sure exactly when the CM will switch 
channels, the CMTS duplicates the downstream packet flow on the old and new downstream channels. 

e) The CMTS issues a DCC-REQ command to the CM. 

f) The CM sends a DCC-RSP (depart). The CM then cleans up its queues and state machines as appropriate 
and changes channels. 

g) If there was a downstream channel change, the CM synchronizes to the QAM symbol timing, synchronizes 
the FEC framing, and synchronizes with the MPEG framing. 

h) If the CM has been instructed to re-initialization, it does so with the new upstream and/or downstream 
channel assignment. The CM exits from the flow of events described here, and enters the flow of events 
described in Section 9.2 starting with the recognition of a downstream SYNC message. 

i) The CM searches for a UCD message unless it has been supplied with a copy. 

j) The CM waits for a downstream SYNC message unless it has been instructed not to wait for one. 

k) The CM collects MAP messages unless it already has them available in its cache. 

1) The CM performs initial maintenance and station maintenance unless it has been instructed to skip them. 

m) The CM resumes normal data transmission with its new resource assignment. 

n) The CM sends a DCC-RSP (arrive) message to the CMTS. 

o) The CMTS responds with a DCC-ACK. 

p) The CMTS removes the QoS reservations from the old channels. If the downstream packet flow was 
duplicated, the packet duplication would also be removed on the old downstream channel. 

q) The CM re-issues its DSA-REQ command. 

r) The CMTS reserves the requested resources and responds with a DSA-RSP. 
s) The CM finishes with a DSA-ACK. 
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Figure 9-17. DCC Example Operational Flow 
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Figure 9-18. Dynamically Changing Channels: CMTS View Part 1 
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Figure 9-19. Dynamically Changing Channels: CMTS View Part 2 
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Figure 9-20. Dynamically Changing Channels: CM View Part 1^ 

a. The state "Obtain Upstream Parameters" links to the state machine in Figure 9-1. 
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Figure 9-21. Dynamically Changing Channels: CM View Part 2 
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Appendix B. Parameters and Constants 



System 


Name 


Time Reference 


Minimum 
Value 


Default 
Value 


Maximum 
Value 


CMTS 


T11 


Wait for a DCC Response on the old channel 






300 ms 


CM 


T12 


Wait for a DCC Acknowledge 






300 ms 


CMTS 


T13 


Maximum holding time for QOS resources for 
DCC 






1 sec 


CM 


T14 


Minimum time after a DSx reject-temp-DCC 
and the next retry of DSx command 


2 sec 






CMTS 


DCC-REQ 
Retries 


Number of retries on Dynamic Channel 
Change Request 


3 


CM 


DCC-RSP 
Retries 


Number of retries on Dynamic Channel 
Change Response 


3 



C. 1.3,1 Modem Capabilities Encoding 

CU.Lll 

CL3.L12 DCCSupport 

The value is the DCC support of the CM. 

Type Length Value 
5.12 1 0 = DCCisnot supported 

1 - DCC is supported 
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Gr2 Qual i ty of S orv i oo Ro l atod Enood i ngo 

C.2Ai3\2 Classifici ' Idcntificf ' 
G3,3i3i3 Scmcc Flow Identifier 

Scryicc Identifier 
C.3.3.6.S Tolerated Gmnt Jitter 
C, 3, 3, 6, 11 Unsolicited Grant Time Rcfi}rcnee 
€,3.3.10,3 Payload Header Suppression Index (PIISI) 

C.4 Confirmation Code 

Confirmation Code is one of the following .... 

reject-temporary-DCC(25) 

• reject-temporary-DCC(25) indicates that the requested resources are not available on the current channels at 
this time, and the CM should re-request them on new channels after completing a channel change in response 
to a DCC command which the CMTS will send. If no DCC is received, the CM must wait for a time of at 
least T14 before re-requesting the resources on the current channels. 

C.4.1 Confirmation Codes for Dynamic Channel Change 

The CM may return in the DCC-RSP message an appropriate rejection code from Appendix C. 1.3.1. It may also 
return one of the following Confirmation Codes which are unique to DCC-RSP. 

depart(180) 
arrive(181) 

reject-already-there( 1 82) 
The Confirmation Codes MUST be used in the following way: 

• depart(l 80) indicates the CM is on the old channel and is about to perform the jump to the new channel. 

• arrive(l 81) indicates the CM has performed the jump and has arrived at the new channel. 

• reject-already-there(182) indicates that the CMTS has asked the CM to move to a channel that it is already 
occupying. 

C.4.2 Confirmation Codes for Major Errors 



33 



csco-docsis-dcc-00Q530a .f m Data-Over-Cable Service Interface Specifications 



Appendix H. Multiple Upstream Channels 

This section is informational. In case of conflict between this section and any normative section of this 
specification, the normative section takes precedence. 

Section 5.2 describes support for multiple upstream and multiple downstream channels within a DOCSIS 
domain. The permutations that a CM may see on the cable segment it is attached to include: 

• single downstream and single upstream per cable segment 

• single downstream and multiple upstreams per cable segment 

• multiple downstreams and single upstream per cable segment 

• multiple downstreams and multiple upstreams per cable segment 

A typical application that will require one upstream and one downsteam per CM is web browsing. Web browsing 
tends to have asymmetrical bandwidth requirements that match closely to the asymmetrical bandwidth of 
DOCSIS. 

A typical application that will require access to one of multiple upstreams per CM is IP Telephony. IP Telephony 
tends to have symmetrical bandwidth requirements. If there is a large concentration of CMs in a geographical 
area all served by the same fiber node, more than one upstream may be required in order to provide sufficient 
bandwidth and prevent call blocking. 

A typical application that will require access to one of multiple downstreams per CM is IP streaming video. IP 
streaming video tends to have extremely large downstream bandwidth requirements. If there is a large 
concentration of CMs in a geographical area all served by the same fiber node, more than one downstream may 
be required in order to provide sufficient bandwidth and to deliver multiple IP Video Streams to multiple CMs. 

A typical application that will require multiple downstreams and multiple upstreams is when the above 
applications are combined, and it is more economical to have multiple channels than it is to physically subdivide 
the HFC network. 

The role of the CM in these scenarios would be to be able to move between multiple upstreams and between 
multiple downstreams. The role of the CMTS would be to manage the traffic load to all attached CMs, and 
balance the traffic between the multiple upstreams and downstreams by dynamically moving the CMs based 
upon their resource needs and the resources available. 

This appendix looks at the implementation considerations for these cases. Specifically, the first and last 
application are profiled. These examples are meant to illustrate one topology and one implementation of that 
topology. 
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H.1 Single Downstream and Single Upstream per Cable Segment 

This section presents an example of a single downstream channel and four upstream channels. In Figure H-1 , the 
four upstream channels are on separate fibers serving four geographical communities of modems. The CMTS has 
access to the one downstream and all four upstreams, while each CM has access to the one downstream and only 
one upstream. 



Downstream Laser & 
CMTS Upstream Receiver 



4 



4 



4 



Fiber Nodes 



Coax 



Fiber 



<st>i 



€X3 



€t>i 
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Coax 



Figure H-1. Single Downstream and Single Upstream Channels per CM 



In this topology, the CMTS transmits Upstream Channel Descriptors (UCDs) and MAPs for each of the four 
upstream channels related to the shared downstream channel. 

Unfortunately, each CM cannot determine which fiber branch it is attached to because there is no way to convey 
the geographical information on the shared downstream channel. At initialization, the CM randomly picks a 
UCD and its corresponding MAP. The CM then chooses an Initial Maintenance opportunity on that channel and 
transmits a Ranging Request. 



The CMTS will receive the Ranging Request and will redirect the CM to the appropriate upstream channel 
identifier by specifying the upstream channel ID in the Ranging Response. The CM MUST then use the channel 
ID of the Ranging Response, not the channel ID on which the Ranging Request was initiated. This is necessary 
only on the first Ranging Response received by the CM. The CM SHOULD continue the ranging process 
normally and proceed to wait for station maintenance lEs. 

From then on, the CM will be using the MAP that is appropriate to the fiber branch to which it is connected. If 
the CM ever has to redo initial maintenance, it may start with its previous known UCD instead of choosing one at 
random. 



35 



csco-docsis-dcc-000530a.fm 



Data-Over-Cable Service Interface Specifications 



A number of constraints are imposed by this topology: 

• All Initial Maintenance opportunities across all fiber nodes must be aligned. When the CM chooses a UCD to 
use and then subsequently uses the MAP for that channel, the CMTS must be prepared to receive a Ranging 
Request at that Initial Maintenance opportunity. Note that only the initialization intervals must be aligned. 
Once the CM is successfully ranged on an upstream channel, its activities need only be aligned with other 
users on the same upstream channel. In Figure H-1, ordinary data transmission and requests for bandwidth 
may occur independently across the four upstream channels. 

• All of the upstream channels on different nodes should operate at the same frequency or frequencies unless it 
is known that no other upstream service will be impacted due to a CM transmission of a Ranging Request on 
a "wrong" frequency during an Initial Maintenance opportunity. If the CM chooses an upstream channel 
descriptor arbitrarily, it could transmit on the wrong frequency if the selected UCD applied to an upstream 
channel on a different fiber node. This could cause initial maintenance to take longer. However, this might be 
an acceptable system trade-off in order to keep spectrum management independent between cable segments. 

• All of the upstream channels may operate at different symbol rates. However, there is a trade-off involved 
between the time it takes to acquire ranging parameters and flexibility of upstream channel symbol rate. If 
upstream symbol rates are not the same, the CMTS would be unable to demodulate the Ranging Request if it 
was transmitted at the wrong symbol rate for the particular upstream receiver of the channel. The result would 
be that the CM would retry as specified in the RFI specification and then would eventually try other upstream 
channels associated with the currently used downstream. Increasing the probability of attempting ranging on 
multiple channels increases CM initialization time but using different symbol rates on different fiber nodes 
allows flexibility in setting the degree of burst noise mitigation. 

• All Initial Maintenance opportunities on different channels may use different burst characteristics so that the 
CMTS can demodulate the Ranging Request. Again, this is a trade-off between time to acquire ranging and 
exercising flexibility in setting physical layer parameters among different upstream channels. If upstream 
burst parameters for Initial Maintenance are not the same, the CMTS would be unable to demodulate the 
Ranging Request if it was transmitted with the wrong burst parameters for the particular channel. The result 
would be that the CM would retry the Ranging Request as specified in the RFI specification and then would 
eventually try other upstream channels associated with the currently used downstream. Increasing the proba- 
bility of attempting ranging on multiple channels increases CM initialization time but using different burst 
parameters for Initial Maintenance on different fiber nodes allows the ability to set parameters appropriate for 
plant conditions on a specific node. 

H.2 Multiple Downstreams and Multiple Upstreams per Cable Segment 

This section presents a more complex set of examples of CMs which are served by several downstream channels 
and several upstream channels and where those upstream and downstream channels are part of one MAC 
domain. The interaction of Initial Maintenance, normal operation, and Dynamic Channel Change are profiled, as 
well as the impact of the multiple downstreams using synchronized or unsynchronized timestamps. 

Synchronized timestamps refer to both downstream paths transmitting a time stamp that is derived from a 
common clock frequency and have common time bases. The timestamps on each downstream do not have to be 
transmitted at the same time in order to be considered synchronized. 

H.2.1 Topologies 

Suppose two downstream channels are used in conjunction with four upstream channels as shown in Figure H-2. 
In all three topologies, there are two geographical communities of modems, both served by the same two 
downstream channels. The difference in the topologies is found in their upstream connectivity. 
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Figure H-2. IVIultiple Downstream and Muitiple Upstream Channels per CIVI 
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Topology #1 has the return path' from each fiber node connected to a dedicated set of upstream receivers. A CM 
will see both downstream channels, but only one upstream channel which is associated with one of the two 
downstream channels. 

Topology #2 has the return path from each fiber node combined and then split across all upstream receivers. A 
CM will see both downstream channels and all four upstream channels in use with both downstream channels. 

Topology #3 has the return path from each fiber node split and then sent to multiple upstream receivers, each 
associated with a different downstream channel. A CM will see both downstream channels, and one upstream 
channel associated with each of the two downstream channels. 

Topology #1 is the typical topology in use. Movement between downstreams can only occur if the timestamps on 
both downstreams are synchronized. Topology #2 and Topology #3 are to compensate for downstreams which 
have unsynchronized timestamps, and allow movement between downstream channels as long as the upstream 
channels are changed at the same time. 

The CMs are capable of single frequency receive and single frequency transmit. 
H.2.2 Normal Operation 

Table H-1 lists MAC messages that contain Channel IDs. 



Table H-1. MAC Messages with Channel IDs 



MAC Message 


Downsteam Channel ID 


Upstream Channel ID 


UCD 


Yes 


Yes 


MAP 


No 


Yes 


RNG-REQ 


Yes 


No 


RNG-RSP 


No 


Yes 


DCC-REQ 


Yes 


Yes 



With unsynchronized timestamps: 

• Since upstream synchronization relies on downstream timestamps, each upstream channel must be associated 
with the time stamp of one of the downstream channels. 

• The downstream channels should only transmit MAP messages and UCD messages that pertain to their asso- 
ciated upstream channels. 

With synchronized timestamps: 

• Since upstream synchronization can be obtained from either downstream channel, all upstreams can be asso- 
ciated with any downstream channel. 

• All MAPs and UCDs for all upstream channels should be sent on all downstream channels. The UCD mes- 
sages contains a Downstream Channel ID so that the CMTS can determine with the RNG-REQ message 
which downstream channel the CM is on. Thus the UCD messages on each dovmstream will contain different 
Downstream Channel IDs even though they might contain the same Upstream Channel ID. 

H.2.3 Initial maintenance 

When a CM performs initial maintenance, the topology is unknown and the timestamp consistency between 
downstreams is unknown. Therefore, the CM chooses either downstream channel and any one of the UCDs sent 
on that downstream channel. 
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In both cases: 

• The upstream channel frequencies within a physical upstream or combined physical upstreams must be dif- 
ferent. 

• The constraints specified in Section H. 1 apply. 

H.2.4 Dynamic Channel Change 

With unsynchronized timestamps: 

• When a DCC-REQ is given, it must contain new upstream and new downstream frequency pairs that are both 
associated with the same timestamp. 

• When the CM resynchronizes to the new downstream, it must allow for timestamp resynchronization without 
re-ranging unless instructed to do so with the DCC-REQ conmiand. 

• Topology #1 will support channel changes between local upstream channels present within a cable segment, 
but will not support changes between downstream channels. Topology #2 and #3 will support upstream and 
downstream channel changes on all channels within the fiber node as long as the new upstream and down- 
stream channel pair are associated with the same timestamp. 

With synchronized timestamps: 

• Downstream channel changes and upstream channel changes are independent of each other. 

• Topology #1 , #2, and #3 will support changes between all upstream and all downstream channels present 
within the cable segment. 
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